General SIP Parameters

The general SIP parameters are described in the table below.

General SIP Parameters

Parameter

Description

'Classify By Proxy Set Mode'

configure voip > sip-definition settings > classify-by-proxy-set-mode

[ClassifyByProxySetMode]

Defines which IP address to use for classifying the incoming SIP dialog message to a Server-type IP Group, based on Proxy Set.

[0] IP address = (Default) The device checks if the source IP address (ISO Layer 3) of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. If a match is found in the Proxy Set, the call is classified to the IP Group.
[1] Contact Header = The device checks if the IP address in the SIP Contact header of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. This is only applicable if the header contains a SIP URI that has an IP address (not hostname) in the host part. If a match is found in the Proxy Set, the call is classified to the IP Group. This option is useful, for example, when the source IP address is an internal address like when the Mediant CE SBC is deployed in Azure. The Mediant CE on Azure communicates using internal IP addresses and thus, the Internal Load Balancer doesn't perform SNAT translation and packets typically arrive with the IP address of the active Signaling Component virtual machine, instead of the Load Balancer.
[2] Both = The device first checks if the source IP address (ISO Layer 3) of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. Only if there is no match, does the device check if the IP address in the SIP Contact header of the incoming SIP dialog matches an IP address in the Proxy Set.

Note:

To enable classification by Proxy Set, configure the IP Group table's 'Classify By Proxy Set' parameter to Enable (see Configuring IP Groups).
Classification using the SIP Contact header is supported only when the header's SIP URI has an IP address (not a DNS hostname).
For IDS, only the source IP address is used (see Configuring IDS Policies).
For TLS Contexts, only the source IP address is used. (If a Proxy Set is not found, the TLS Context configured for the SIP Interface is used.)

configure voip > sip-definition settings > max-sdp-sess-ver-id

[MaxSDPSessionVersionId]

Defines the maximum number of characters allowed in the SDP body's "o=" (originator and session identifier) field for the session ID and session version values.

Below is an example of an "o=" line with session ID and session version values (in bold):

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5

The valid value range is 1,000 to 214,748,3647 (default).

configure voip > sip-definition settings > unreg-on-startup

[UnregisterOnStartup]

Enables the device to unregister all user Accounts that were registered with the device, upon a device restart. During device start-up, each Account sends a REGISTER message (containing "Contact: *") to unregister all contact URIs belonging to its Address-of-Record (AOR), and then a second after they are unregistered, the device re-registers the Account.

[0] = (Default) Disable
[1] = Enable

To configure Accounts, see Configuring Registration Accounts.

'Send Reject (503) upon Overload'

configure voip > sip-definition settings > reject-on-ovrld

[SendRejectOnOverload]

Disables the sending of SIP 503 (Service Unavailable) responses upon receipt of new SIP dialog-initiating requests when the device's CPU is overloaded and thus, unable to accept and process new SIP messages.

[0] Disable = No SIP 503 response is sent when CPU overloaded.
[1] Enable  = (Default) SIP 503 response is sent when CPU overloaded.

Note: Even if the parameter is disabled (i.e., 503 is not sent), the device still discards the new SIP dialog-initiating requests when the CPU is overloaded.

'SIP 408 Response upon non-INVITE'

configure voip > sip-definition settings > enbl-non-inv-408

[EnableNonInvite408Reply]

Enables the device to send SIP 408 responses (Request Timeout) upon receipt of non-INVITE transactions. Disabling this response complies with RFC 4320/4321. By default, and in certain circumstances such as a timeout expiry, the device sends a SIP 408 Request Timeout in response to non-INVITE requests (e.g., REGISTER).

[0] Disable = SIP 408 response is not sent upon receipt of non-INVITE messages (to comply with RFC 4320).
[1] Enable = (Default) SIP 408 response is sent upon receipt of non-INVITE messages, if necessary.

'Remote Management by SIP NOTIFY'

configure voip > sip-definition settings > sip-remote-reset

[EnableSIPRemoteReset]

Enables a specific device action upon the receipt of a SIP NOTIFY request, where the action depends on the value in the Event header.

[0] Disable (default)
[1] Enable

The action depends on the Event header value:

"Event: check-sync;reboot=false": Triggers the regular Automatic Update feature (if Automatic Update has been enabled on the device).
"Event: check-sync;reboot=true": Triggers a device restart.
"Event: soft-sync": Triggers the device to disconnect all current calls.
If the 'reboot=' parameter is not specified in the Event header, it defaults to 'true' (i.e., triggers a device restart).

Note: The Event header value is proprietary to AudioCodes.

'Max SIP Message Length'

[MaxSIPMessageLength]

Defines the maximum size (in Kbytes) for each SIP message that can be sent over the network. The device rejects messages exceeding this user-defined size.

The valid value range is 1 to 100. The default is 100.

[SIPForceRport]

Determines whether the device sends SIP responses to the UDP port from where SIP requests are received even if the 'rport' parameter is not present in the SIP Via header.

[0] = (Default) Disabled. The device sends the SIP response to the UDP port defined in the Via header. If the Via header contains the 'rport' parameter, the response is sent to the UDP port from where the SIP request is received.
[1] = Enabled. SIP responses are sent to the UDP port from where SIP requests are received even if the 'rport' parameter is not present in the Via header.

'Reject Cancel after Connect'

configure voip > sip-definition settings > rej-cancel-after-conn

[RejectCancelAfterConnect]

Enables or disables the device to accept or reject SIP CANCEL requests received after the receipt of a 200 OK in response to an INVITE (i.e., call established). According to the SIP standard, a CANCEL can be sent only during the INVITE transaction (before 200 OK), and once a 200 OK response is received the call can be rejected only by a BYE request.

[0] Disable = (Default) Accepts a CANCEL request received during the INVITE transaction by sending a 200 OK response and terminates the call session.
[1] Enable = Rejects a CANCEL request received during the INVITE transaction by sending a SIP 481 (Call/Transaction Does Not Exist) response and maintains the call session.

configure voip > sip-definition settings > call-info-list

[CallInfoListMode]

Defines how the device handles SIP Call-Info headers with multiple values in outgoing SIP messages.

[0] = The device sends the outgoing SIP message with a Call-Info header for each value.
[1] = The device sends the outgoing SIP message with a single Call-Info header that contains all the values (comma-separated list) per RFC 3261.

configure voip > sip-definition settings > verify-rcvd-requri

[VerifyRecievedRequestUri]

Enables the device to reject SIP requests (e.g., ACK, BYE, or re-INVITE) whose user part in the Request-URI is different from the user part in the Contact header of the last sent SIP request.

[0] = (Default) Disable. Even if the user part is different, the device accepts the SIP request.
[1] = Enable. If the user part in the Contact header of the previous SIP request is different to the user part in the Request-URI for in-dialog requests, the device rejects the SIP request. A BYE request is responded with a SIP 481, a re-INVITE request is responded with a SIP 404, and an ACK request is ignored.
[2] = If the user part in the Contact header of the previous SIP request is different to the user part in the Request-URI for dialog-initiating INVITE requests, the device rejects the SIP request.
Verify dialog-initiating INVITE for all required conditions (Via, Source IP and user in Request-URI)
[3] = Verify dialog-initiating INVITE and in-dialog requests.

The [VerifyRecievedRequestUri] parameter functions together with the [RegistrarProxySetID] parameter, as follows:

Handling Dialog-Initiating INVITEs: If the [VerifyRecievedRequestUri] parameter is configured to [2] or [3] and the [RegistrarProxySetID] parameter is configured to some Proxy Set, the device accepts dialog-initiating INVITE requests received from the registrar at which the Accounts (configured in the Accounts table) are registered. For dialog-initiating INVITE requests received from the registrar on a specific SIP Interface, the following rules apply (listed according to priority):
The top-most Via header must contain a host-resolved IP address of the registrar; otherwise, the device drops the INVITE request.
The source IP address must be the same as the IP address of the registrar; otherwise, the device rejects the requests and sends a SIP 403 (Forbidden) response to the registrar.
The user part, specified in the Request-URI header, must be identical to the Contact user part configured for the associated Account, and the Account must be registered. Otherwise, the device rejects the request with a SIP 404 (Not Found) response. If the [RegistrarProxySetID] parameter is not configured or no Accounts are configured, the device accepts the dialog-initiating INVITE request.
Handling In-dialog Requests: If the [VerifyRecievedRequestUri] parameter is configured to [1] or [3], for all incoming in-dialog requests (including ACK and CANCEL), the device checks if the Request-URI user part matches the remote Contact user part (i.e., the Contact user configured for the Account). If there is no match, the device rejects the request and sends a SIP 481 response for requests such as BYE and CANCEL, or a SIP 404 for other requests, and for ACK it doesn't send any response.

[RegistrarProxySetID]

Defines a Proxy Set for the registrar. The parameter functions together with the [VerifyRecievedRequestUri] parameter. For more information, see the description of the [VerifyRecievedRequestUri] parameter.

The default value is -1 (not defined).

Note: This setting assumes that the SIP Interface has only one registrar.

'Max Number of Active Calls'

configure voip > sip-definition settings > max-nb-of--act-calls

[MaxActiveCalls]

Defines the maximum number of simultaneous active calls supported by the device. If the maximum number of calls is reached, new calls are not established.

The valid range is 1 to the maximum number of supported channels. The default value is the maximum available channels (i.e., no restriction on the maximum number of calls).

'Enable Early Media'

early-media

[EnableEarlyMedia]

Global parameter enabling the Early Media feature for sending media (e.g., ringing) before the call is established.

You can also configure this feature per specific calls, using IP Profiles ('Early Media' parameter). For a detailed description of the parameter and for configuring the feature, see Configuring IP Profiles.

Note: If the feature is configured for a specific profile, the settings of the global parameter is ignored for calls associated with the profile.

[RemoveToTagInFailureResponse]

Determines whether the device removes the ‘to’ header tag from final SIP failure responses to INVITE transactions.

[0] = (Default) Do not remove tag.
[1] = Remove tag.

'Fax Signaling Method'

fax-sig-method

[IsFaxUsed]

Global parameter defining the SIP signaling method for establishing and transmitting a fax session when the device detects a fax.

You can also configure this feature per specific calls, using IP Profiles ('Fax Signaling Method' parameter). For a detailed description of the parameter, see Configuring IP Profiles .

Note: If you configure this feature for a specific IP Profile, the device ignores this global parameter for calls associated with the IP Profile.

fax-vbd-behvr

[FaxVBDBehavior]

Determines the device's fax transport behavior when G.711 VBD coder is negotiated at call start.

[0] = (Default) If the device is configured with a VBD coder (see the [CodersGroup] parameter) and is negotiated OK at call start, then both fax and modem signals are sent over RTP using the bypass payload type (and no mid-call VBD or T.38 Re-INVITEs occur).
[1] = If the [IsFaxUsed] parameter is set to 1, the channel opens with the [FaxTransportMode] parameter set to 1 (relay). This is required to detect mid-call fax tones and to send T.38 Re-INVITE messages upon fax detection. If the remote party supports T.38, the fax is relayed over T.38.

Note:

If VBD coder negotiation fails at call start and if the [IsFaxUsed] parameter is set to 1 (or 3), then the channel opens with the [FaxTransportMode] parameter set to 1 (relay) to allow future detection of fax tones and sending of T.38 Re-INVITES. In such a scenario, the [FaxVBDBehavior] parameter has no effect.
This feature can be used only if the remote party supports T.38 fax relay; otherwise, the fax fails.

[NoAudioPayloadType]

Defines the payload type of the outgoing SDP offer.

The valid value range is 96 to 127 (dynamic payload type). The default is 0 (i.e. NoAudio is not supported). For example, if set to 120, the following is added to the INVITE SDP:

a=rtpmap:120 NoAudio/8000\r\n

Note: For incoming SDP offers, NoAudio is always supported.

'SIP Transport Type'

configure voip > sip-definition settings > app-sip-transport-type

[SIPTransportType]

Determines the default transport layer for outgoing SIP calls initiated by the device.

[0] UDP (default)
[1] TCP
[2] TLS (SIPS)

Note:

It's recommended to use TLS for communication with a SIP Proxy and not for direct device-to-device communication.
For received calls (i.e., incoming), the device accepts all these protocols.

'Display Default SIP Port'

configure voip > sip-definition settings > display-default-sip-port

[DisplayDefaultSIPPort]

Enables the device to add the default SIP port 5060 (UDP/TCP) or 5061 (TLS) to outgoing messages that are received without a port. This condition also applies to manipulated messages where the resulting message has no port number. The device adds the default port number to the following SIP headers: Request-Uri, To, From, P-Asserted-Identity, P-Preferred-Identity, and P-Called-Party-ID. If the message is received with a port number other than the default, for example, 5070, the port number is not changed.

An example of a SIP From header with the default port is shown below:

From: <sip:+4000@10.8.4.105:5060;user=phone>;tag=f25419a96a;epid=009FAB8F3E

[0] Disable (default)
[1] Enable

'SIPS'

configure voip > sip-definition settings > enable-sips

[EnableSIPS]

Enables secured SIP (SIPS URI) connections over multiple hops.

[0] Disable (default)
[1] Enable

When the [SIPTransportType] parameter is set to 2 (i.e., TLS) and the parameter [EnableSIPS] is disabled, TLS is used for the next network hop only. When the [SIPTransportType] parameter is set to 2 or 1 (i.e., TCP or TLS) and [EnableSIPS] is enabled, TLS is used through the entire connection (over multiple hops).

Note: If the parameter is enabled and the [SIPTransportType] parameter is set to 0 (i.e., UDP), the connection fails.

'TCP/TLS Connection Reuse'

tcp-conn-reuse

[EnableTCPConnectionReuse]

Enables the reuse of an established TCP or TLS connection between the device and a SIP user agent (UA) for subsequent SIP requests sent to the UA. Any new out-of-dialog requests (e.g., INVITE or REGISTER) use the same secured connection. One of the benefits of enabling the parameter is that it may improve performance by eliminating the need for additional TCP/TLS handshakes with the UA, allowing sessions to be established rapidly.

[0] Disable = The device uses a new TCP or TLS connection with the UA.
[1] Enable = (Default) The device uses the same TCP or TLS connection for all SIP requests with the UA.

Note:

For SIP responses, the device always uses the same TCP/TLS connection, regardless of the parameter settings.

'Fake TCP Alias'

configure voip > sip-definition settings > fake-tcp-alias

[FakeTCPalias]

Enables the reuse of the same TCP/TLS connection for sessions with the same user even if the 'alias' parameter is not present in the SIP Via header of the initial INVITE.

[0] Disable = (Default) TCP/TLS connection reuse occurs only if the 'alias' parameter is present in the Via header of the initial INVITE (according to RFC 5923).
[1] Enable = Enables the reuse of TCP/TLS connections regardless of the presence of the 'alias' parameter.

Note: To enable TCP/TLS connection reuse, see the [EnableTCPConnectionReuse] parameter.

'Reliable Connection Persistent Mode'

configure voip > sip-definition settings > reliable-conn-persistent

[ReliableConnectionPersistentMode]

Enables all reusable TCP/TLS (reliable) connections to be persistent (i.e., not released).

When sending a SIP message, the device’s reliable connection reuse policy determines if current connections to the specific destination are reused.

Persistent connections ensure less network traffic due to fewer setting up and tearing down of reliable connections and reduced latency on subsequent requests because there is no need for initial TCP handshakes. Persistent connections may reduce the number of costly TLS handshakes to establish security associations, in addition to the initial TCP connection setup.

[0] Disable = (Default) The device releases all reliable connections that aren't being used. However, if the destination is a Proxy server (configured in the Proxy Sets table), the reliable connection is always persistent, regardless of the parameter's settings.
[1] Enable = The device makes reusable reliable connections to all destinations persistent and doesn't release them (see note below). A persistent connection stays open even when it's no longer in use (i.e., not used by any SIP dialog or transaction, and isn't associated with a registered user).

Note:

The device releases unnecessary persistent TLS connections to prevent them from accumulating and reaching the device's maximum number of supported TLS connections (refer to the document Release Notes). If the number of incoming TLS connections exceeds 80% of the maximum, the device closes incoming TLS connections that aren’t in use (i.e., no active SIP dialogs and not associated with a registered user) and that are kept open only because they are persistent.
Similar to the above note, the device releases reliable (TCP/TLS) connections that aren’t in use and are kept open only because they are persistent, when reaching 80% of the maximum number of supported reliable connections.
The device sends the SNMP alarm acTLSSocketsLimitAlarm when the number of incoming TLS connections exceeds 95% of the maximum TLS connections supported by the device.
Connection reuse depends on the [EnableTCPConnectionReuse] parameter; for incoming connections, reuse also depends on SIP message characteristics (presence of Via header’s ‘alias’ parameter in initial request).

'TCP Timeout'

configure voip > sip-definition settings > tcp-timeout

[SIPTCPTimeout]

Defines the Timer B (INVITE transaction timeout timer) and Timer F (non-INVITE transaction timeout timer), as defined in RFC 3261, when the SIP transport type is TCP.

The valid range is 0 to 60 sec. The default is 0, which means that the parameter's value is set to 64 multiplied by the value of the [SipT1Rtx] parameter. For example, if you configure [SipT1Rtx] to 500 msec (0.5 sec) and leave the [SIPTCPTimeout] parameter at its default value (0), the actual value of [SIPTCPTimeout] is 32 sec (64 x 0.5 sec).

'SIP Destination Port'

configure voip > sip-definition settings > sip-dst-port

[SIPDestinationPort]

Defines the SIP destination port for sending initial SIP requests.

The valid range is 1 to 65534. The default port is 5060.

Note: SIP responses are sent to the port specified in the Via header.

'Use Tel URI for Asserted Identity'

configure voip > sip-definition settings > uri-for-assert-id

[UseTelURIForAssertedID]

Defines the format of the URI in the P-Asserted-Identity and P-Preferred-Identity headers.

[0] Disable = (Default) The format is 'sip:'.
[1] Enable = The format is 'tel:'.

configure voip > sip-definition settings > p-preferred-id-list

[PPreferredIdListMode]

Defines the number of P-Preferred-Identity SIP headers included in the outgoing SIP message when the header contains multiple values.

[0] = (Default) The device includes multiple P-Preferred-Identity SIP headers in the outgoing message, for example:
Incoming message containing a P-Preferred-Identity header with multiple values:
P-Preferred-Identity: <sip:someone@test.org>,<tel:+123456789>
Outgoing message sent with multiple P-Preferred-Identity headers, each with a value:
P-Preferred-Identity: <sip:someone@test.org>
P-Preferred-Identity: <tel:+123456789>
[1] = The device includes only one P-Preferred-Identity header in the outgoing message, for example:
Incoming message containing multiple P-Preferred-Identity headers:
P-Preferred-Identity: <sip:someone@test.org>
P-Preferred-Identity: <tel:+123456789>
Outgoing message sent with a single P-Preferred-Identity header containing the multiple values:
P-Preferred-Identity: <sip:someone@test.org>,<tel:+123456789>

Note:

If more than two P-Preferred-Identity headers are received in the incoming message, the device keeps the first two headers (if configured to 0) or the first header (if configured to 1), and removes the others in the outgoing message.

'GRUU'

configure voip > sbc settings > gruu

[EnableGRUU]

Determines whether the Globally Routable User Agent URIs (GRUU) mechanism is used, according to RFC 5627. This is used for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog.

[0] Disable (default)
[1] Enable

A GRUU is a SIP URI that routes to an instance-specific UA and can be reachable from anywhere. There are a number of contexts in which it is desirable to have an identifier that addresses a single UA (using GRUU) rather than the group of UA’s indicated by an Address of Record (AOR). For example, in call transfer where user A is talking to user B, and user A wants to transfer the call to user C. User A sends a REFER to user C:

REFER sip:C@domain.com SIP/2.0

From: sip:A@domain.com;tag=99asd

To: sip:C@domain.com

Refer-To: (URI that identifies B's UA)

The Refer-To header needs to contain a URI that user C can use to place a call to user B. This call needs to route to the specific UA instance that user B is using to talk to user A. User B should provide user A with a URI that has to be usable by anyone. It needs to be a GRUU.

Obtaining a GRUU: The mechanism for obtaining a GRUU is through registrations. A UA can obtain a GRUU by generating a REGISTER request containing a Supported header field with the value “gruu”. The UA includes a “+sip.instance” Contact header parameter of each contact for which the GRUU is desired. This Contact parameter contains a globally unique ID that identifies the UA instance. The global unique ID is created from one of the following:
If the REGISTER is per the device’s client (endpoint), it is the MAC address concatenated with the phone number of the client.
If the REGISTER is per device, it is the MAC address only.
When using TP, “User Info” can be used for registering per endpoint. Thus, each endpoint can get a unique id – its phone number. The globally unique ID in TP is the MAC address concatenated with the phone number of the endpoint.

If the remote server doesn’t support GRUU, it ignores the parameters of the GRUU. Otherwise, if the remote side also supports GRUU, the REGISTER responses contain the “gruu” parameter in each Contact header. The parameter contains a SIP or SIPS URI that represents a GRUU corresponding to the UA instance that registered the contact. The server provides the same GRUU for the same AOR and instance-id when sending REGISTER again after registration expiration. RFC 5627 specifies that the remote target is a GRUU target if its’ Contact URL has the "gr" parameter with or without a value.

Using GRUU: The UA can place the GRUU in any header field that can contain a URI. It must use the GRUU in the following messages: INVITE request, its 2xx response, SUBSCRIBE request, its 2xx response, NOTIFY request, REFER request and its 2xx response.

'User-Agent Information'

configure voip > sip-definition settings > user-agent-info

[UserAgentDisplayInfo]

Defines the string that is used in the SIP User-Agent and Server response headers. When configured, the string <UserAgentDisplayInfo value>/software version' is used, for example:

User-Agent: myproduct/7.40A.600.203

If not configured, the default string, "<product-name>/<<software version>>" is used, for example:

User-Agent: AudioCodes-Sip-Gateway/<swver>

The maximum string length is 50 characters.

Note: The software version number and preceding forward slash (/) cannot be modified. Therefore, it is recommended not to include a forward slash in the parameter's value (to avoid two forward slashes in the SIP header, which may cause problems).

'SDP Session Owner'

configure voip > sip-definition settings > sdp-session-owner

[SIPSDPSessionOwner]

Defines the value of the Owner line ('o' field) in outgoing SDP messages.

The valid range is a string of up to 39 characters. The default is "AudioCodesGW".

For example:

o=AudioCodesGW 1145023829 1145023705 IN IP4 10.33.4.126

Note: The parameter is applicable only when the device creates a new SIP message (and SDP) such as when the device plays a ringback tone. The parameter is not applicable to SIP messages that the device receives from one end and sends to another (i.e., doesn't modify the SDP's 'o' field).

configure voip > sip-definition settings > sdp-ver-nego

[EnableSDPVersionNegotiation]

Enables the device to ignore new SDP re-offers (from the media negotiation perspective) in certain scenarios (such as session expires). According to RFC 3264, once an SDP session is established, a new SDP offer is considered a new offer only when the SDP origin value is incremented. In scenarios such as session expires, SDP negotiation is irrelevant and thus, the origin field is not changed.

Even though some SIP devices don’t follow this behavior and don’t increment the origin value even in scenarios where they want to re-negotiate, the device can assume that the remote party operates according to RFC 3264, and in cases where the origin field is not incremented, the device doesn't re-negotiate SDP capabilities.

[0] Disable = (Default) The device negotiates any new SDP re-offer, regardless of the origin field.
[1] Enable = The device negotiates only an SDP re-offer with an incremented origin field.

'Subject'

configure voip > sip-definition settings > usr-def-subject

[SIPSubject]

Defines the Subject header value in outgoing INVITE messages. If not specified, the Subject header isn't included (default).

The maximum length is up to 50 characters.

configure voip > sip-definition settings > enable-ptime

[EnablePtime]

Defines if the 'ptime' attribute is included in the SDP.

[0] = Remove the 'ptime' attribute from SDP.
[1] = (Default) Include the 'ptime' attribute in SDP.

'3xx Behavior'

3xx-behavior

[3xxBehavior]

Determines the device's behavior regarding call identifiers when a 3xx response is received for an outgoing INVITE request. The device can use the same call identifiers (Call-ID, To, and From tags) or change them in the new initiated INVITE.

[0] Forward = (Default) Use different call identifiers for a redirected INVITE message.
[1] Redirect = Use the same call identifiers in the new INVITE as the original call.

configure voip > sip-definition settings > retry-after-mode

[RetryAfterMode]

Defines the device’s behavior when it receives a SIP 503 (Service Unavailable) containing a Retry-After header, in response to a SIP message (e.g., REGISTER) sent to a proxy server.

In certain scenarios (depending on the value of this parameter), the device considers the proxy as offline (down) for the number of seconds specified in the Retry-After header. During this timeout, the device doesn't send any SIP messages to the proxy. This condition is indicated in the syslog message as "server is now Unavailable - setting Retry-After timer to x secs".

[1] = (Default) Handle Locally. The device considers the proxy as offline regardless of the type of SIP message sent to the proxy for which the 503 response was received.
[0] = Transparent. The behavior depends on the type of SIP message sent to the proxy for which the 503 response was received:
SIP OPTIONS message: The device considers the proxy as offline.
SIP REGISTER message generated (created) by the device: The device doesn't send REGISTER messages to the proxy for this specific registration process (i.e., Accounts table or SBC User Information table) during the timeout specified in the Retry-After header of the 503 response. However, the device considers the proxy as online and therefore, it continues sending traffic of other entities to the proxy.
All other SIP dialogs (e.g., INVITE): The device ignores the Retry-After header and forwards the 503 response transparently to the other user agent.

'Retry-After Time'

configure voip > sip-definition settings > retry-aftr-time

[RetryAfterTime]

Defines the time (in seconds) used in the Retry-After header when a 503 (Service Unavailable) response is generated by the device.

The time range is 0 to 3,600. The default is 0.

'Fake Retry After'

fake-retry-after

[FakeRetryAfter]

Defines if the device, upon receiving a SIP 503 response without a Retry-After header, behaves as if the 503 response included a Retry-After header and with the period (in seconds) specified by the parameter.

[0] Disable (default)
Any positive value (in seconds) for defining the period

When enabled, this feature allows the device to operate with Proxy servers that do not include the Retry-After SIP header in SIP 503 (Service Unavailable) responses to indicate an unavailable service.

The Retry-After header is used with the 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting SIP client. The device maintains a list of available proxies, by using the Keep-Alive mechanism. The device checks the availability of proxies by sending SIP OPTIONS every keep-alive timeout to all proxies.

If the device receives a SIP 503 response to an INVITE, it also marks that the proxy is out of service for the defined "Retry-After" period.

'P-Associated-URI Header'

p-associated-uri-hdr

[EnablePAssociatedURIHeader]

Determines the device usage of the P-Associated-URI header. This header can be received in 200 OK responses to REGISTER requests. When enabled, the first URI in the P-Associated-URI header is used in subsequent requests as the From/P-Asserted-Identity headers value.

[0] Disable (default)
[1] Enable

Note: P-Associated-URIs in registration responses is handled only if the device is registered per endpoint (using the User Information file).

'Source Number Preference'

configure voip > sip-definition settings > src-nb-preference

[SourceNumberPreference]

Defines the SIP header from which the source (calling) number is obtained in incoming INVITE messages.

If not configured or if any string other than "From" or "Pai2" is configured, the calling number is obtained from a specific header using the following logic:
a. P-Preferred-Identity header.
b. If the above header is not present, then the first P-Asserted-Identity header is used.
c. If the above header is not present, then the Remote-Party-ID header is used.
d. If the above header is not present, then the From header is used.
"From" = The calling number is obtained from the From header.
"Pai2" = The calling number is obtained using the following logic:
e. If a P-Preferred-Identity header is present, the number is obtained from it.
f. If no P-Preferred-Identity header is present and two P-Asserted-Identity headers are present, the number is obtained from the second P-Asserted-Identity header.
g. If only one P-Asserted-Identity header is present, the calling number is obtained from it.

Note:

The "From" and "Pai2" values are not case-sensitive.
Once a URL is selected, all the calling party parameters are set from this header. If P-Asserted-Identity is selected and the Privacy header has the value 'id', the calling number is assumed restricted.

'Reason Header'

configure voip > sip-definition settings > reason-header

[EnableReasonHeader]

Enables the usage of the SIP Reason header.

[0] Disable
[1] Enable (default)

'Gateway Name'

configure voip > sip-definition settings > gw-name

[SIPGatewayName]

Defines a name for the device (e.g., device123.com), which is used as the host part for the SIP URI in the From header for outgoing messages. If not configured, the device's IP address is used instead (default).

The valid value is a string of up to 100 characters. By default, no value is defined.

Note:

Ensure that the parameter value is the one with which the proxy has been configured with to identify the device.
If you enable keep-alive by SIP OPTIONS messages with the proxy (see the Proxy Set parameter 'Proxy Keep-Alive'), you can configure, using the [UseGatewayNameForOptions] parameter, if the device's IP address, the proxy's IP address, or the device's name (configured by the [SIPGatewayName] parameter) is used in the keep-alive SIP OPTIONS messages (host part of the Request-URI).
The parameter can also be configured for an IP Group (in the IP Groups table).

configure voip > sip-definition settings > zero-sdp-behavior

[ZeroSDPHandling]

Determines the device's response to an incoming SDP that includes an IP address of 0.0.0.0 in the SDP's Connection Information field (i.e., "c=IN IP4 0.0.0.0").

[0] = (Default) Sets the IP address of the outgoing SDP's c= field to 0.0.0.0.
[1] = Sets the IP address of the outgoing SDP c= field to the IP address of the device. If the incoming SDP doesn’t contain the "a=inactive" line, the returned SDP contains the "a=recvonly" line.

'Delayed Offer'

configure voip > sip-definition settings > delayed-offer

[EnableDelayedOffer]

Determines whether the device sends the initial INVITE message with or without an SDP. Sending the first INVITE without SDP is typically done by clients for obtaining the far-end's full list of capabilities before sending their own offer. (An alternative method for obtaining the list of supported capabilities is by using SIP OPTIONS, which is not supported by every SIP agent.)

[0] Disable = (Default) The device sends the initial INVITE message with an SDP.
[1] Enable = The device sends the initial INVITE message without an SDP.

configure voip > sip-definition settings > digest-auth-uri-mode

[SIPDigestAuthorizationURIMode]

Defines if the device includes or excludes URI parameters for the Digest URI in the SIP Proxy-Authorization or Authorization headers of the request that the device sends in reply to a received SIP 401 (Unauthorized) or 407 (Proxy Authentication Required) response.

Below shows an example of a request with an Authorization header containing a Digest URI (shown in bold):

Authorization: Digest username="alice at AudioCodes.com",realm="AudioCodes.com",nonce="",response="",uri="sip:AudioCodes.com"

[0] = (Default) The device sends the request without a Digest URI.
[1] = The device sends the request with a Digest URI, which is set to the same value as the URI in the original Request-URI.

configure voip > sip-definition settings > crypto-life-time-in-sdp

[DisableCryptoLifeTimeInSDP]

Enables the device to send "a=crypto" lines without the lifetime parameter in the SDP. For example, if the SDP contains "a=crypto:12 AES_CM_128_HMAC_SHA1_80 inline:hhQe10yZRcRcpIFPkH5xYY9R1de37ogh9G1MpvNp|2^31", it removes the lifetime parameter "2^31".

[0] Disable (default)
[1] Enable

'AES-256 Encryption Key'

configure voip > sip-definition settings > encrypt-key-aes256

[EncryptKeyAES256]

Defines the AES-256 encryption key for encrypting (and decrypting) the SIP header value.

The valid value is a string of 32 characters. By default, no value is defined.

For more information, see Configuring SIP Header Value Encryption.

'Contact Restriction'

contact-restriction

[EnableContactRestriction]

Determines whether the device sets the Contact header of outgoing INVITE requests to ‘anonymous’ for restricted calls.

[0] Disable (default)
[1] Enable

configure voip > sip-definition settings > use-aor-in-refer-to-header

[UseAORInReferToHeader]

Defines the source for the SIP URI set in the Refer-To header of outgoing REFER messages.

[0] = (Default) Use SIP URI from Contact header of the initial call.
[1] = Use SIP URI from To/From header of the initial call.

'User-Information Usage'

configure voip > sip-definition settings > user-inf-usage

[EnableUserInfoUsage]

Enables the usage of the User Information, which is loaded to the device in the User Information Auxiliary file. For more information on User Information, see User Information File.

[0] Disable (default)
[1] Enable

Note: For the parameter to take effect, a device restart is required.

configure voip > sip-definition settings > handle-reason-header

[HandleReasonHeader]

Determines whether the device uses the value of the incoming SIP Reason header for Release Reason mapping.

[0] = Disregard Reason header in incoming SIP messages.
[1] = (Default) Use the Reason header value for Release Reason mapping.

[EnableSilenceSuppInSDP]

Determines the device's behavior upon receipt of SIP Re-INVITE messages that include the SDP's 'silencesupp:off' attribute.

[0] = (Default) Disregard the 'silecesupp' attribute.
[1] = Handle incoming Re-INVITE messages that include the 'silencesupp:off' attribute in the SDP as a request to switch to the Voice-Band-Data (VBD) mode. In addition, the device includes the attribute 'a=silencesupp:off' in its SDP offer.

Note: The parameter is applicable only if the G.711 coder is used.

configure voip > sip-definition settings > rport-support

[EnableRport]

Enables the usage of the 'rport' parameter in the Via header.

[0] = Disabled (default)
[1] = Enabled

The device adds an 'rport' parameter to the Via header of each outgoing SIP message. The first Proxy that receives this message sets the 'rport' value of the response to the actual port from where the request was received. This method is used, for example, to enable the device to identify its port mapping outside a NAT.

If the Via header doesn't include the 'rport' parameter, the destination port of the response is obtained from the host part of the Via header.
If the Via header includes the 'rport' parameter without a port value, the destination port of the response is the source port of the incoming request.
If the Via header includes 'rport' with a port value (e.g., rport=1001), the destination port of the response is the port indicated in the 'rport' parmeter.

[EnableRekeyAfter181]

Enables the device to send a re-INVITE with a new (different) SRTP key (in the SDP) if a SIP 181 response is received ("call is being forwarded"). The re-INVITE is sent immediately upon receipt of the 200 OK (when the call is answered).

[0] = Disable (default)
[1] = Enable

Note: The parameter is applicable only if SRTP is used.

configure voip > sip-definition settings > number-of-active-dialogs

[NumberOfActiveDialogs]

Defines the maximum number of concurrent, outgoing SIP REGISTER dialogs. The parameter is used to control the registration rate.

The valid range is 1 to 20. The default is 20.

Note:

Once a 200 OK is received in response to a REGISTER message, the REGISTER message is not considered in this maximum count limit.
The parameter applies only to outgoing REGISTER messages (i.e., incoming is unlimited).

'Network Node ID'

configure voip > sip-definition settings > net-node-id

[NetworkNodeId]

Defines the Network Node Identifier of the device for Avaya UCID.

The valid value range is1 to 0x7FFF. The default is 0.

Note:

To use this feature, you must set the parameter to any value other than 0.
To enable the generation by the device of the Avaya UCID value and adding it to the outgoing INVITE sent to the IP Group (Avaya entity), use the IP Groups table's parameter 'UUI Format'.

'Enable Microsoft Extension'

configure voip > sip-definition settings > microsoft-ext

[EnableMicrosoftExt]

Enables the modification of the called and calling number for numbers received with Microsoft's proprietary "ext=xxx" parameter in the SIP INVITE URI user part. Microsoft Office Communications Server sometimes uses this proprietary parameter to indicate the extension number of the called or calling party.

[0] Disable (default)
[1] Enable

For example, if a calling party makes a call to telephone number 622125519100 Ext. 104, the device receives the SIP INVITE (from Microsoft's application) with the URI user part as INVITE sip:622125519100;ext=104@10.1.1.10 (or INVITE tel:622125519100;ext=104). If the parameter [EnableMicrosofExt] is enabled, the device modifies the called number by adding an "e" as the prefix, removing the "ext=" parameter, and adding the extension number as the suffix (e.g., e622125519100104). Once modified, the device can then manipulate the number further, using the Number Manipulation tables to leave only the last 3 digits (for example) for sending to a PBX.

configure voip > sip-definition settings > sip-uri-for-diversion-header

[UseSIPURIForDiversionHeader]

Defines the URI format in the SIP Diversion header.

[0] = 'tel:' (default)
[1] = 'sip:'

configure voip > sip-definition settings > 100-to-18x-timeout

[TimeoutBetween100And18x]

Defines the timeout (in msec) between receiving a 100 Trying response and a subsequent 18x response. If a 18x response is not received within this timeout period, the call is disconnected.

The valid range is 0 to 180,000 (i.e., 3 minutes). The default is 32000 (i.e., 32 sec).

configure voip > sip-definition settings > ignore-remote-sdp-mki

[IgnoreRemoteSDPMKI]

Determines whether the device ignores the Master Key Identifier (MKI) if present in the SDP received from the remote side.

[0] = (Default) Disable
[1] = Enable

configure voip > sip-definition settings > sdp-ecan-frmt

[SDPEcanFormat]

Defines the echo canceller format in the outgoing SDP. The 'ecan' attribute is used in the SDP to indicate the use of echo cancellation.

[0] = (Default) The 'ecan' attribute appears on the 'a=gpmd' line.
[1] = The 'ecan' attribute appears as a separate attribute.
[2] = The 'ecan' attribute is not included in the SDP.
[3] = The 'ecan' attribute and the 'vbd' parameter are not included in the SDP.

Note: The parameter is applicable only when the [IsFaxUsed] parameter is set to 2, and for re-INVITE messages generated by the device as result of modem or fax tone detection.

'First Call Ringback Tone ID'

configure voip > sip-definition settings > 1st-call-rbt-id

[FirstCallRBTId]

Defines the index of the first ringback tone in the CPT file. This option enables an Application server to request the device to play a distinctive ringback tone to the calling party according to the destination of the call. The tone is played according to the Alert-Info header received in the 180 Ringing SIP response (the value of the Alert-Info header is added to the value of the parameter).

The valid range is -1 to 1,000. The default is -1 (i.e., play standard ringback tone).

Note:

It is assumed that all ringback tones are defined in sequence in the CPT file.
In case of an MLPP call, the device uses the value of the parameter plus 1 as the index of the ringback tone in the CPT file (e.g., if this value is set to 1, then the index is 2, i.e., 1 + 1).

'Presence Publish IP Group ID'

[PresencePublishIPGroupId]

Assigns the IP Group (by ID) configured for the Skype for Business Server (presence server). This is where the device sends SIP PUBLISH messages to notify of changes in presence status of Skype for Business users when making and receiving calls using third-party endpoint devices.

For more information on integration with Microsoft presence, see Microsoft Skype for Business Presence of Third-Party Endpoints.

'Microsoft Presence Status'

[EnableMSPresence]

Enables the device to notify (using SIP PUBLISH messages) Skype for Business Server (presence server) of changes in presence status of Skype for Business users when making and receiving calls using third-party endpoint devices.

[0] Disable (default)
[1] Enable

For more information on integration with Microsoft presence, see Microsoft Skype for Business Presence of Third-Party Endpoints.

'Media IP Version Preference'

configure voip > media settings > media-ip-ver-pref

[MediaIPVersionPreference]

Global parameter that defines the preferred RTP media IP addressing version (IPv4 or IPv6) for outgoing SIP calls. You can also configure this feature per specific calls, using IP Profiles ('Media IP Version Preference' parameter). For a detailed description of the parameter and for configuring this feature in the IP Profiles table, see Configuring IP Profiles.

configure voip > message settings > inbound-map-set

[GWInboundManipulationSet]

Assigns a Manipulation Set ID for manipulating incoming responses of requests that the device initiates.

The Manipulation Set is defined using the [MessageManipulations] parameter. By default, no manipulation is done (i.e. Manipulation Set ID is set to -1).

For more information, see Configuring SIP Message Manipulation.

configure voip > message settings > outbound-map-set

[GWOutboundManipulationSet]

Assigns a Manipulation Set ID for manipulating outgoing requests that the device initiates.

The Manipulation Set is defined using the [MessageManipulations] parameter. By default, no manipulation is done (i.e. Manipulation Set ID is set to -1).

For more information, see Configuring SIP Message Manipulation.

'WebSocket Keep-Alive Period'

configure voip > sip-definition settings > websocket-keepalive

[WebSocketProtocolKeepAlivePeriod]

Defines how often (in seconds) the device sends ping messages (keep alive) to check whether the WebSocket session with the Web client is still connected.

The valid value is 5 to 2000000. The default is 0 (i.e., ping messages are not sent).

For more information on WebSocket, see SIP over WebSocket.

Note:

The device always replies to WebSocket ping control messages with pong messages.

'Registered User MOS Observation Window'

configure voip > qoe reg-user-voice-quality > mos-observ-win

[RegUserMosObservationWindow]

Defines the length of each interval (in hours) in the observation window (12 intervals) for calculating average MOS of calls belonging to users registered with the device.

The valid value is 1 or 2. The default is 1.

As the device measures MOS in 12 intervals, if configured to 1, then MOS is measured over a 12 hour period; if configured to 2, then MOS is calculated over a 24 hour period. It measures the average and minimum MOS per interval. Intervals without calls are not used in the calculation.

For more information on this feature, see Configuring Voice Quality for Registered Users.

'MOS Stored Timeout For No Calls'

configure voip > qoe reg-user-voice-quality > mos-stored-timeout-for-no-calls

[MosStoredTimeoutForNoCalls]

Defines the duration (in minutes) of no calls after which the MOS measurement is reset (0 and gray color). In addition, if an alternative IP Profile is configured for the Quality of Service rule and is currently being used, the device changes back to the original IP Profile.

The valid value range is 1 to 1,440. The default is 60.

For more information on this feature, see Configuring Voice Quality for Registered Users.

configure voip > sip-definition settings > message-policy-reject-response-type

[MessagePolicyRejectResponseType]

Defines the SIP response code that the device sends when it rejects an incoming SIP message due to a matched Message Policy in the Message Policies table, whose 'Send Reject' parameter is configured to Policy Reject.

The default is 400 "Bad Request".

To configure Message Policies, see Configuring SIP Message Policy Rules.

[ENUMAllowNonDigits]

Defines if non-digits can be included in ENUM queries sent by the device to an ENUM server for retrieving a SIP URI address for an E.164 telephone number (destination).

[0] = (Default) Disable – non-digits are not accepted in ENUM queries. For example: 9.2.0.0.3.0.9.3.0.3.0.2.5.3.4.4.2.5.7.7.7.8.My_Domain
[1] = Enable – non-digits are accepted in ENUM queries (request). For example: 0.0.0.0.0.2.3.3.3.3.2.2.*.9.9.j.a.k.s.*.j.k.a.n.d.b.j.s.+.My_Domain

ENUM queries can be used for IP-to-IP routing with Call Setup Rules (see Configuring SBC IP-to-IP Routing Rules and Configuring Call Setup Rules).

'Regions Connectivity Dial Plan'

configure voip > sbc settings > regions-connectivity-dial-plan

[RegionsConnectivityDialPlan]

Defines the Dial Plan that the device must search in the Dial Plans table to check if the source and destination Teams sites share a common group number. If they do, the call is a direct media call.

For more information, see Using Dial Plans for Microsoft Local Media Optimization

Note: The ini file parameter is a table, using the following syntax:

[ RegionsConnectivityDialPlan ]

FORMAT Index = RCDialPlan;

RegionsConnectivityDialPlan 0 = "NameofDialPlan";

[ \RegionsConnectivityDialPlan ]

Note: The feature is applicable only to Teams-to-PSTN calls.

configure voip > sip-definition settings > preserve-multipart-content-type

[PreserveMultipartContentType]

Defines the device's handling of the SIP Content-Type header's value when the device sends a SIP message that has multiple bodies.

[0] = (Default) Disabled. The device sets the type parameter in the Content-Type header to "multipart/mixed" and adds a unique value to the 'boundary' parameter of the Content-Type header.
[1] = Enabled. The device doesn’t change the type or boundary parameter of the Content-Type header. For example, if the incoming message contains 'Content-Type: multipart/relative;boundary=<someUniqueValue>', then this is how the Content-Type will be in the outgoing message.

Out-of-Service (Busy Out) Parameters

Retransmission Parameters

'SIP T1 Retransmission Timer'

configure voip > sip-definition settings > t1-re-tx-time

[SipT1Rtx]

Defines the time interval (in msec) between the first transmission of a SIP message and the first retransmission of the same message.

The default is 500.

Note: The time interval between subsequent retransmissions of the same SIP message starts with SipT1Rtx. For INVITE requests, it is multiplied by two for each new retransmitted message. For all other SIP messages, it is multiplied by two until SipT2Rtx. For example, assuming SipT1Rtx = 500 and SipT2Rtx = 4000:

The first retransmission is sent after 500 msec.
The second retransmission is sent after 1000 (2*500) msec.
The third retransmission is sent after 2000 (2*1000) msec.
The fourth retransmission and subsequent retransmissions until [SIPMaxRtx] are sent after 4000 (2*2000) msec.

'SIP T2 Retransmission Timer'

configure voip > sip-definition settings > t2-re-tx-time

[SipT2Rtx]

Defines the maximum interval (in msec) between retransmissions of SIP messages (except for INVITE requests).

The default is 4000.

Note: The time interval between subsequent retransmissions of the same SIP message starts with SipT1Rtx and is multiplied by two until SipT2Rtx.

'SIP Maximum RTX'

configure voip > sip-definition settings > sip-max-rtx

[SIPMaxRtx]

Defines the maximum number of UDP transmissions of SIP messages (first transmission plus retransmissions).

The range is 1 to 30. The default is 7.

'Number of RTX Before Hot-Swap'

configure voip > sip-definition proxy-and-registration > nb-of-rtx-b4-hot-swap

[HotSwapRtx]

Defines the number of retransmitted INVITE/REGISTER messages before the call is routed (hot swap) to another Proxy/Registrar.

The valid range is 1 to 30. The default is 3.

For example, if configured to 3 and no response is received from an IP destination, the device attempts another three times to send the call to the IP destination. If still unsuccessful, it attempts to redirect the call to another IP destination.

Note: The parameter is also used for alternative routing (see Alternative Routing Based on IP Connectivity.

configure voip > sip-definition settings > usr2usr-hdr-frmt

[UserToUserHeaderFormat]

Defines the interworking between the SIP INVITE's User-to-User header and the ISDN User-to-User (UU) IE data.

[0] = (Default) SIP header format: X-UserToUser.
[1] = SIP header format: User-to-User with Protocol Discriminator (pd) attribute (according to IETF Internet-Draft draft-johnston-sipping-cc-uui-04). For example:

User-to-User=3030373435313734313635353b313233343b3834;pd=4

[2] = SIP header format: User-to-User with encoding=hex at the end and pd embedded as the first byte (according to IETF Internet-Draft draft-johnston-sipping-cc-uui-03). For example:

User-to-User=043030373435313734313635353b313233343b3834; encoding=hex

where "04" at the beginning of this message is the pd.

[3] = Interworks the SIP User-to-User header containing text format to ISDN UUIE in hexadecimal format, and vice versa. For example:

SIP Header in text format:

User-to-User=01800213027b712a;NULL;4582166;

Translated to hexadecimal in the ISDN UUIE:

303138303032313330323762373132613b4e554c4c3b343538323136363b

The Protocol Discriminator (pd) used in UUIE is "04" (IUA characters).